리눅스 커널

1. 서론

1.1 커널의 정의: 운영체제의 심장부

운영체제(OS)의 가장 핵심적인 구성 요소를 지칭하는 커널(Kernel)은 그 이름이 암시하듯, 단단한 껍질 속의 씨앗처럼 시스템의 중심에 위치한다.1 커널은 하드웨어와 소프트웨어 사이의 근본적인 중재자로서, 전화기, 노트북, 서버 등 모든 형태의 컴퓨팅 장치에서 하드웨어의 모든 주요 기능을 제어하는 역할을 수행한다.1 사용자가 직접 상호작용하는 웹 브라우저나 파일 탐색기와 같은 응용 프로그램들은 ’사용자 공간(User Space)’에 존재하며, 이들은 커널이 제공하는 ’시스템 호출 인터페이스(System Call Interface, SCI)’라는 엄격하게 정의된 통로를 통해서만 하드웨어 자원에 접근할 수 있다.1 이러한 구조는 시스템의 안정성과 보안을 보장하는 핵심적인 설계 원리이다. 커널을 강력한 경영진(하드웨어)을 위해 분주하게 일하는 개인 비서에 비유할 수 있다. 이 비서는 직원과 대중(사용자)으로부터 오는 메시지와 요청(프로세스)을 경영진에게 전달하고, 자원의 위치를 기억하며(메모리 관리), 누가 언제 얼마나 경영진을 만날 수 있는지(프로세스 관리) 결정하는 중추적인 역할을 담당한다.1 따라서 리눅스 커널을 이해하는 것은 단순히 OS의 한 부분을 분석하는 것을 넘어, 현대 컴퓨팅 시스템이 어떻게 작동하는지에 대한 근본적인 원리를 탐구하는 과정이다. 커널 자체는 완전한 운영체제가 아니며, 컴파일러, 시스템 유틸리티, 셸(Shell)과 같은 사용자 공간 프로그램들이 결합되었을 때 비로소 완전한 리눅스 운영체제가 구성된다.3

1.2 리눅스의 보급: 전 지구적 현상

리눅스 커널의 영향력은 특정 분야에 국한되지 않고 전 세계 컴퓨팅 환경 전반에 걸쳐 있다. 오늘날 리눅스는 세계에서 가장 빠른 슈퍼컴퓨터 TOP500 리스트에 등재된 모든 시스템에서 사용되는 유일한 운영체제이며, 이는 리눅스의 압도적인 성능과 확장성을 증명한다.4 인터넷을 지탱하는 상위 100만 개의 웹 서버 중 96.4% 이상이 리눅스 기반으로 운영되고 있으며, 이는 서버 시장에서의 확고한 지배력을 보여준다.4 또한, 안드로이드 운영체제의 핵심으로서 전 세계 수십억 개의 스마트폰에 탑재되어 있으며, 이는 리눅스가 역사상 가장 널리 설치된 범용 운영체제 커널임을 의미한다.4 리눅스의 영향력은 여기서 그치지 않는다. 자동차(테슬라, 현대자동차 등), 스마트 TV(삼성, LG), 네트워크 라우터, 심지어 스페이스X의 팰컨 9 로켓에 이르기까지 광범위한 임베디드 시스템의 두뇌 역할을 수행하며 우리 삶의 거의 모든 기술적 측면에 깊숙이 자리 잡고 있다.4 이처럼 리눅스의 광범위한 보급은 이 커널의 기술적 우수성, 유연성, 그리고 오픈소스 모델의 성공을 입증하는 명백한 증거이며, 그 내부 구조와 작동 원리에 대한 깊이 있는 고찰의 필요성을 더욱 부각시킨다.

1.3 안내서의 목적 및 구조

본 안내서는 리눅스 커널에 대한 심층적이고 분석적인 고찰을 제공하는 것을 목표로 한다. 이를 위해 단순한 기능 나열을 넘어, 커널의 핵심 설계 철학, 주요 서브시스템의 정교한 메커니즘, 그리고 끊임없이 진화하는 개발 생태계를 다각적으로 조명할 것이다. 안내서는 다음과 같은 구조로 전개된다. 첫째, 리눅스 커널의 탄생 배경과 역사적 발전 과정을 추적하여 오늘날의 모습에 이르게 된 핵심적인 결정들을 분석한다. 둘째, 모놀리식 커널이라는 구조적 선택과 이를 보완하는 모듈 시스템의 독창성을 탐구하며 리눅스의 설계 철학을 해부한다. 셋째, 프로세스 관리, 메모리 관리, 가상 파일 시스템이라는 세 가지 핵심 서브시스템의 내부 동작 원리를 상세히 분석한다. 넷째, 전 세계적인 협업을 가능하게 하는 독특한 오픈소스 개발 모델과 커뮤니티 구조를 살펴본다. 다섯째, Windows NT, XNU와 같은 다른 현대 운영체제 커널과의 비교를 통해 리눅스 커널의 상대적인 장단점과 위치를 조명한다. 마지막으로, 보안 문제와 Rust 언어 도입과 같은 현재의 도전 과제와 미래 방향성을 논하며 안내서를 마무리한다.

2. 리눅스 커널의 기원과 진화

2.1 학생의 프로젝트에서 세계적인 현상으로

리눅스 커널의 역사는 1991년, 핀란드 헬싱키 대학교의 한 학생이었던 리누스 토르발스(Linus Torvalds)의 개인적인 호기심에서 시작되었다.4 당시 교육용으로 널리 사용되던 미닉스(MINIX) 운영체제의 라이선스가 학술적 용도로만 제한되는 것에 불만을 느낀 그는, 인텔 386 프로세서의 기능을 최대한 활용할 수 있는 자신만의 운영체제 커널을 직접 만들어보기로 결심했다.4 이 프로젝트는 처음에는 토르발스 개인의 취미에 불과했으나, 인터넷을 통해 소스 코드를 공개하고 전 세계 개발자들의 참여를 유도하면서 폭발적인 성장을 이루었다.5 이처럼 미미하게 시작된 프로젝트가 오늘날 전 세계 컴퓨팅 인프라의 근간을 이루게 된 과정은 기술 역사상 가장 극적인 성공 사례 중 하나로 평가받는다.

2.2 GNU 프로젝트와의 공생 관계

리눅스 커널의 성공을 논할 때, 리처드 스톨먼(Richard Stallman)이 이끌던 GNU 프로젝트와의 관계를 빼놓을 수 없다. GNU 프로젝트는 1983년부터 ’완전한 유닉스 호환 자유 소프트웨어 시스템’을 만드는 것을 목표로 컴파일러(GCC), 셸(Bash), 핵심 유틸리티 등 운영체제에 필요한 거의 모든 구성 요소를 개발해왔다.4 하지만 1990년대 초까지 GNU는 정작 시스템의 심장 역할을 할 자체 커널(GNU Hurd)을 완성하지 못하고 있었다.4 바로 이 시점에 리눅스 커널이 등장했다. 이는 마치 잘 만들어진 자동차 차체와 부품은 모두 준비되었지만 엔진이 없던 상황에, 강력한 엔진이 나타난 것과 같았다.

이러한 상황은 리눅스 커널의 발전에 있어 결정적인 기회로 작용했다. 토르발스는 초기에 상업적 재배포를 금지하는 자신만의 라이선스를 사용했으나, 곧 GNU 프로젝트의 풍부한 도구들과 결합하기 위해 자신의 커널을 GNU GPLv2(General Public License version 2) 라이선스로 변경하는 중대한 결정을 내렸다.4 이 결정은 리눅스 커널이 자유 소프트웨어로 남도록 보장했을 뿐만 아니라, 이미 완성되어 있던 GNU의 사용자 공간 도구들과 완벽하게 결합하여 완전한 기능의 자유 운영체제를 탄생시키는 기폭제가 되었다.5 이 역사적 배경 때문에 자유 소프트웨어 재단(FSF)은 이 운영체제를 ’리눅스’가 아닌 ’GNU/리눅스’로 불러야 한다고 주장하며, 이는 커널과 사용자 공간 시스템의 공생 관계를 상징적으로 보여준다.4 이처럼 리눅스의 성공은 토르발스의 기술적 성취뿐만 아니라, 시기적절하게 존재했던 GNU 생태계와 GPL이라는 법적, 철학적 기반이 완벽한 ’퍼펙트 스톰’을 이루었기에 가능했다.

2.3 커널 개발의 주요 이정표

리눅스 커널은 초기 텍스트 기반의 콘솔 형태에서 출발하여 지속적인 발전을 거듭했다.4 주요 버전 업데이트를 거치며 현대 운영체제가 갖추어야 할 핵심 기능들이 순차적으로 추가되었다.5 초기에는 인텔 x86 아키텍처에 국한되었으나, 곧 다양한 프로세서 아키텍처로 이식되면서 적용 범위를 넓혔다. X11 윈도잉 시스템과 그놈(GNOME), KDE와 같은 데스크톱 환경이 등장하면서 개인용 컴퓨터 시장에서도 점차 입지를 다지기 시작했다.4 1990년대 중반부터는 슈퍼컴퓨팅 분야에서 주목받기 시작했는데, NASA와 같은 기관들이 고가의 유닉스 시스템을 리눅스 기반의 저렴한 컴퓨터 클러스터로 대체하면서 그 성능과 안정성을 입증했다.4 이는 서버 시장으로의 본격적인 진출을 알리는 신호탄이었으며, LAMP(Linux, Apache, MySQL, PHP/Perl/Python) 스택의 등장은 웹 서버 시장에서 리눅스의 지배력을 확고히 하는 계기가 되었다.4 21세기에 들어서는 안드로이드 운영체제의 기반이 되면서 모바일 시장을 석권했고, 임베디드 시스템으로의 확장을 통해 그 영향력을 우리 생활 곳곳으로 넓혀갔다.4

2.4 생태계의 확장

리눅스 커널의 발전은 단순히 기술적인 성장에만 머무르지 않았다. 커널을 중심으로 강력한 상업적 생태계가 형성되면서 그 성장은 더욱 가속화되었다. 레드햇(Red Hat)이나 수세(SUSE)와 같은 기업들은 오픈소스인 리눅스 커널을 기반으로 안정성과 기술 지원을 강화한 상용 배포판(예: Red Hat Enterprise Linux)을 출시했다.1 이는 안정성과 장기적인 유지보수를 중시하는 기업 시장에서 리눅스가 신뢰를 얻고 확산되는 데 결정적인 역할을 했다. 즉, 자발적인 커뮤니티의 열정과 상업적 기업의 체계적인 지원이 결합되면서 취미로 시작된 프로젝트가 전 세계의 핵심 인프라로 자리 잡게 된 것이다. 대한민국에서도 카카오뱅크가 국내 금융권 최초로 전산 시스템에 리눅스를 도입하고, 한국거래소가 차세대 시스템을 리눅스 기반으로 전환하는 등 4, 리눅스는 이제 가장 높은 수준의 안정성과 보안을 요구하는 분야에서도 그 가치를 인정받고 있다.

3. 설계 철학: 모듈식 팔다리를 가진 모놀리식 심장

3.1 모놀리식 대 마이크로커널 논쟁

운영체제 커널의 아키텍처는 크게 모놀리식(Monolithic)과 마이크로(Micro) 방식으로 나뉜다. 이 둘의 선택은 시스템의 성능, 안정성, 유연성을 결정하는 근본적인 설계 철학의 차이를 반영한다.

• 모놀리식 커널 (Monolithic Kernel): 모놀리식 구조는 프로세스 관리, 메모리 관리, 파일 시스템, 장치 드라이버 등 운영체제의 핵심적인 서비스 대부분을 단일 주소 공간, 즉 커널 공간(Kernel Space) 내에서 실행하는 방식이다.6 이 구조의 가장 큰 장점은 성능이다. 커널 내의 각 구성 요소들은 별도의 주소 공간을 넘나들 필요 없이 단순한 함수 호출(function call)을 통해 서로 통신하므로 매우 빠르고 효율적이다.8 하지만 이는 치명적인 단점을 내포한다. 모든 구성 요소가 하나의 거대한 프로그램처럼 묶여 있기 때문에, 드라이버 하나에 발생한 작은 버그가 시스템 전체를 멈추게 하는 ’커널 패닉(Kernel Panic)’으로 이어질 수 있다.8 또한, 새로운 기능을 추가하거나 기존 기능을 수정하려면 커널 전체를 다시 컴파일하고 시스템을 재부팅해야 하는 경직성을 가진다.6
• 마이크로커널 (Microkernel): 마이크로커널은 이러한 모놀리식의 단점을 극복하기 위해 등장했다. 이 구조는 커널의 역할을 최소화하여, 메모리 관리, 기본적인 프로세스 스케줄링, 프로세스 간 통신(IPC)과 같은 가장 본질적인 기능만을 커널 공간에 남겨둔다.6 파일 시스템, 장치 드라이버, 네트워크 스택과 같은 나머지 서비스들은 모두 별개의 사용자 공간 프로세스로 구현된다.6 이 방식의 장점은 명확하다. 각 서비스가 독립된 프로세스로 실행되므로, 드라이버 하나가 멈추더라도 해당 서비스만 재시작하면 될 뿐 시스템 전체에 영향을 주지 않아 안정성과 내결함성이 뛰어나다.8 기능 추가 역시 새로운 프로세스를 실행하는 것만으로 가능해 유연성이 높다. 하지만 이는 상당한 성능 저하를 감수해야 한다. 사용자 공간의 파일 시스템 서비스가 커널의 IPC 기능을 통해 디스크 드라이버 서비스와 통신해야 하는 등, 서비스 간의 모든 상호작용이 커널을 거치는 메시지 전달 방식으로 이루어져 컨텍스트 스위칭 오버헤드가 크기 때문이다.6

3.2 리눅스의 실용적 선택: 모놀리식 코어

리눅스 커널은 명백히 모놀리식 아키텍처를 채택하고 있다.6 이러한 설계 결정은 시스템의 전반적인 성능을 최우선으로 고려한 결과이다. 리눅스는 커널의 핵심 서브시스템들이 직접적이고 효율적으로 통신할 수 있도록 하여, 마이크로커널에서 발생하는 통신 오버헤드를 근본적으로 제거했다.8 이는 특히 고성능 컴퓨팅이나 대규모 서버 환경에서 리눅스가 강력한 경쟁력을 갖게 된 중요한 이유 중 하나이다.

3.3 유연성의 걸작: 적재 가능 커널 모듈 (LKMs)

리눅스는 모놀리식 구조의 본질적인 약점인 경직성을 ’적재 가능 커널 모듈(Loadable Kernel Modules, LKM)’이라는 독창적인 메커니즘을 통해 극복했다. 이는 리눅스 아키텍처의 가장 큰 특징이자 성공 요인으로, 이데올로기적 순수성보다는 실용성을 중시하는 리눅스의 핵심 철학을 보여준다.

LKM은 실행 중인 커널에 시스템 재부팅 없이 동적으로 코드를 추가하거나 제거할 수 있게 해주는 기능이다.10 주로 장치 드라이버나 파일 시스템과 같은 기능들이 모듈 형태로 제공된다.10 예를 들어, 새로운 USB 장치를 시스템에 연결하면, 커널은 해당 장치에 필요한 드라이버 모듈을 자동으로 로드하여 장치를 활성화한다. 사용이 끝나면 해당 모듈을 언로드하여 시스템 자원을 반환할 수 있다. 이 모듈들은 .ko(kernel object) 확장자를 가지며, insmod(삽입), rmmod(제거), lsmod(목록 확인)와 같은 명령어를 통해 수동으로 관리할 수도 있다.10

이 LKM 메커니즘은 리눅스에 마이크로커널의 장점인 유연성과 확장성을 부여하면서도, 모놀리식 코어의 성능을 그대로 유지하게 해주는 절묘한 해결책이다.6 새로운 하드웨어를 지원하기 위해 커널 전체를 재컴파일할 필요가 없으므로 개발 과정이 단순화되고 12, 이는 리눅스 생태계의 폭발적인 성장을 견인한 핵심적인 기술적 기반이 되었다. 하드웨어 제조사들은 자사의 드라이버를 LKM 형태로 제공함으로써, 복잡하고 시간이 많이 소요되는 메인라인 커널 편입 과정을 거치지 않고도 자사 제품이 리눅스에서 동작하도록 할 수 있었다. 이는 리눅스가 타의 추종을 불허하는 광범위한 하드웨어 호환성을 갖게 된 직접적인 원동력이었다.

3.4 사용자 공간과 커널 공간의 이분법

리눅스 시스템은 안정성과 보안을 위해 두 개의 명확히 구분된 실행 영역으로 나뉜다.1

• 사용자 공간 (User Space): 웹 브라우저, 오피스 프로그램, 데이터베이스 등 우리가 일상적으로 사용하는 모든 응용 프로그램과 사용자 프로세스가 실행되는 영역이다.1 이 공간에서 실행되는 프로그램들은 하드웨어에 직접 접근할 수 있는 권한이 없다.13
• 커널 공간 (Kernel Space): 커널 코드가 실행되는 특권 영역이다. 이 공간에서는 CPU, 메모리 등 모든 하드웨어 자원에 대한 무제한적인 접근이 가능하다.13

사용자 공간의 프로세스가 파일을 읽거나 네트워크로 데이터를 전송하는 등 하드웨어 자원이 필요한 작업을 수행하려면, 반드시 ’시스템 호출(System Call)’이라는 정해진 절차를 통해 커널에 서비스를 요청해야 한다.1 커널은 이 요청을 받아 안전성을 검증한 후, 대신 작업을 수행하고 그 결과를 사용자 공간으로 반환한다. 이처럼 엄격한 경계는 악의적이거나 오류가 있는 응용 프로그램이 시스템의 다른 부분이나 커널 자체를 손상시키는 것을 방지하는 근본적인 보호 장치 역할을 한다.3

4. 프로세스 관리와 스케줄링: 동시성의 예술

4.1 리눅스 프로세스와 스레드 모델

운영체제에서 프로세스란 실행 중인 프로그램의 인스턴스를 의미하며, 독립된 메모리 공간과 자원을 할당받는 작업의 기본 단위이다.2 리눅스 커널은 이러한 프로세스의 생성, 소멸, 그리고 실행의 전 과정을 관리한다. 커널 내에서 각 프로세스는 task_struct라는 거대한 자료구조를 통해 표현된다.16 이 구조체에는 프로세스 ID(PID), 프로세스 상태, 메모리 맵, 열린 파일 목록, 우선순위 등 프로세스에 관한 모든 정보가 담겨 있다.

리눅스 프로세스 모델의 가장 중요한 특징 중 하나는 커널 수준에서 프로세스와 스레드를 근본적으로 구분하지 않는다는 점이다. 다른 운영체제들이 프로세스와 스레드를 위한 별개의 자료구조와 관리 메커니즘을 갖는 것과 달리, 리눅스에서 스레드는 단순히 ’경량 프로세스(Lightweight Process, LWP)’로 취급된다.15 즉, 스레드 역시 task_struct 구조체로 표현되는 독립적인 스케줄링 단위이지만, 다른 스레드(또는 프로세스)와 주소 공간, 파일 디스크립터 테이블과 같은 자원을 공유하도록 설정된 것뿐이다.17 이러한 통일된 모델은

clone() 시스템 호출을 통해 구현되는데, 이 함수는 새로 생성될 태스크가 부모와 어떤 자원을 공유할지를 플래그를 통해 세밀하게 제어할 수 있게 해준다.19 이처럼 프로세스와 스레드를 ’태스크(Task)’라는 단일 개념으로 추상화한 것은 커널 스케줄러의 설계를 크게 단순화하고 일관성을 높이는 효과를 가져왔다.

4.2 프로세스 생성: fork(), exec(), clone() 삼중주

리눅스에서 새로운 프로세스를 생성하고 실행하는 과정은 전통적인 유닉스의 방식을 따르며, 주로 fork()와 exec() 시스템 호출의 조합으로 이루어진다.20

• fork(): 이 시스템 호출은 현재 실행 중인 프로세스(부모 프로세스)를 거의 완벽하게 복제하여 새로운 프로세스(자식 프로세스)를 생성한다.21 초기 유닉스에서는 이 과정에서 부모 프로세스의 전체 메모리 공간을 물리적으로 복사했기 때문에 매우 비효율적이었다. 하지만 현대 리눅스는 **‘쓰기 시 복사(Copy-on-Write, CoW)’**라는 최적화 기법을 사용한다.22 CoW 기법 하에서

fork()는 자식 프로세스를 위해 새로운 메모리 공간을 즉시 할당하지 않는다. 대신, 부모와 자식은 동일한 물리 메모리 페이지를 공유하며, 페이지 테이블에만 읽기 전용으로 표시해 둔다. 그러다 부모나 자식 중 어느 한쪽이 공유된 페이지에 데이터를 쓰려고 시도하는 순간, 커널은 그제야 해당 페이지를 복사하여 별도의 쓰기 가능한 사본을 만들어준다. 이 덕분에 fork()는 매우 빠르고 효율적인 연산이 되었다.

• exec(): 이 시스템 호출은 현재 프로세스의 메모리 이미지를 완전히 새로운 프로그램으로 교체한다.21 지정된 실행 파일을 메모리에 로드하고, 프로세스의 실행 흐름을 해당 프로그램의 시작점(entry point)으로 옮긴다.

exec() 호출이 성공하면 기존 프로그램의 코드는 사라지고 다시 돌아오지 않는다.

• clone(): fork()와 스레드 생성의 기반이 되는 더 근본적인 시스템 호출이다.19

fork()가 부모의 모든 것을 복제하는 반면, clone()은 생성될 자식이 부모와 메모리 공간, 파일 시스템 정보, 파일 디스크립터, 시그널 핸들러 등 어떤 자원을 공유할지를 플래그 조합을 통해 매우 정밀하게 제어할 수 있다. 예를 들어, 주소 공간을 공유하도록 clone()을 호출하면 이는 스레드를 생성하는 것과 같다.

이러한 메커니즘을 통해 리눅스에서 새로운 프로그램을 실행하는 전형적인 패턴은 부모 프로세스가 fork()를 호출하여 자식 프로세스를 만들고, 그 자식 프로세스가 exec()를 호출하여 자신을 새로운 프로그램으로 변신시키는 것이다.20 한편, 시스템이 부팅될 때 생성되는 init 프로세스(PID 1)는 모든 사용자 프로세스의 시조 역할을 하며, 부모 프로세스가 먼저 종료되어 고아가 된 ’고아 프로세스(orphan process)’를 입양하여 관리하는 중요한 책임을 진다.10 또한, 부모 프로세스는 wait() 시스템 호출을 사용하여 자식 프로세스가 종료될 때까지 기다리고 종료 상태 정보를 수거함으로써, 자원이 해제되지 않고 시스템에 남아있는 ’좀비 프로세스(zombie process)’의 발생을 방지한다.21

4.3 완전 공정 스케줄러 (CFS): 이상적인 CPU의 모방

리눅스 커널 2.6.23 버전부터 도입된 ’완전 공정 스케줄러(Completely Fair Scheduler, CFS)’는 일반(실시간이 아닌) 프로세스를 위한 기본 스케줄러이다.24 CFS의 설계 목표는 복잡한 휴리스틱을 배제하고, 모든 프로세스에게 CPU 시간을 ‘완벽하게 공정하게’ 분배하는 것이다.16 CFS는 마치 시스템에 무한히 빠른 CPU가 있어서 모든 프로세스를 동시에, 하지만 각자의 우선순위에 비례하는 속도로 실행하는 이상적인 모델을 모방하고자 한다.

• 핵심 개념: 가상 실행 시간 (vruntime): CFS는 전통적인 고정된 ‘타임 슬라이스’ 개념을 사용하지 않는다. 대신, 각 프로세스의 vruntime이라는 값을 추적한다.16

vruntime은 해당 프로세스가 CPU를 실제로 사용한 시간을 나타내는 나노초 단위의 값으로, 실행될수록 계속 증가한다. CFS의 스케줄링 규칙은 극도로 단순하다: 항상 실행 가능한 프로세스들 중에서 vruntime 값이 가장 작은 프로세스를 선택하여 실행한다.16 이 간단한 원칙은 자연스럽게 CPU를 가장 적게 사용한 프로세스에게 실행 기회를 부여하여 공정성을 달성한다.

• 우선순위와 가중치 (nice 값): CFS에서 ’공정함’은 ’동일함’을 의미하지 않는다. 프로세스의 중요도에 따라 CPU 시간을 차등 분배하기 위해 우선순위 개념이 도입된다. 사용자는 nice 명령을 통해 프로세스에 -20(가장 높은 우선순위)부터 +19(가장 낮은 우선순위)까지의 nice 값을 부여할 수 있다.24 커널은 이

nice 값을 내부적인 ’가중치(weight)’로 변환한다. nice 값이 낮을수록(우선순위가 높을수록) 더 큰 가중치를 부여받는다. 이 가중치는 vruntime을 계산할 때 사용되는데, 실제 실행 시간에 가중치의 역수를 곱하여 vruntime 증가분을 계산한다. 따라서 가중치가 높은(우선순위가 높은) 프로세스는 동일한 시간 동안 실행되더라도 vruntime이 더 느리게 증가한다.16 결과적으로, 이 프로세스는 vruntime이 가장 작은 상태에 더 오래 머무르게 되어 스케줄러에 의해 더 자주 선택되고, 더 많은 CPU 시간을 할당받게 된다.

• 레드-블랙 트리를 이용한 효율적인 선택: CFS는 실행 대기 중인 모든 프로세스를 vruntime을 키(key) 값으로 하여 레드-블랙 트리(Red-Black Tree)라는 자료구조에 저장하여 관리한다.16 레드-블랙 트리는 스스로 균형을 맞추는 이진 탐색 트리로, 데이터의 삽입, 삭제, 그리고 최소값 탐색(가장 왼쪽 노드) 연산을 모두 매우 효율적인

O(logN) 시간 복잡도로 수행할 수 있도록 보장한다.25 따라서 수천 개의 프로세스가 실행 대기 중인 상황에서도, CFS는 다음 실행할 프로세스(즉, vruntime이 가장 작은 프로세스)를 거의 즉시 찾아낼 수 있다. 이는 과거의 스케줄러들이 프로세스 목록 전체를 순회하며 O(N)의 시간 복잡도를 가졌던 것과 비교해 엄청난 성능 향상을 이룬 것이다. 이처럼 CFS는 이상적인 모델을 우아한 수학적 원리와 효율적인 자료구조로 구현함으로써, 다양한 워크로드 환경에서 뛰어난 성능과 반응성을 제공한다.

• 목표 지연 시간과 최소 세분성: CFS는 모든 실행 가능한 태스크가 ’목표 지연 시간(target latency)’이라는 특정 기간(예: 20ms) 내에 적어도 한 번은 실행될 기회를 갖도록 노력한다. 각 프로세스에 할당되는 실질적인 타임 슬라이스는 고정된 값이 아니라, (해당 프로세스의 가중치 / 모든 실행 가능 프로세스의 총 가중치) × (목표 지연 시간)의 공식으로 동적으로 계산된다.16 한편, ‘최소 세분성(minimum granularity)’(예: 1ms)이라는 값은 프로세스가 최소한 이 시간만큼은 실행되도록 보장하여, 너무 잦은 컨텍스트 스위칭으로 인한 오버헤드를 방지하는 역할을 한다.24

5. 메모리 관리: 물리적 자원의 가상화

5.1 가상 메모리의 원리

리눅스 커널의 메모리 관리 시스템의 핵심은 ’가상 메모리(Virtual Memory)’라는 강력한 추상화 기법이다. 커널은 물리적인 RAM의 실제 주소를 직접 노출하는 대신, 각 프로세스에게 자신만의 독립적이고 연속적인 가상 주소 공간(Virtual Address Space)을 제공한다.2 이 가상 주소 공간은 일반적으로 32비트 시스템에서는 4GB, 64비트 시스템에서는 훨씬 더 큰 크기를 가지며, 이는 실제 시스템에 장착된 물리 메모리의 크기와 무관하다. 이 추상화는 다음과 같은 결정적인 이점을 제공한다.

• 격리 및 보호: 각 프로세스는 자신만의 고유한 가상 주소 공간에서 실행되므로, 다른 프로세스의 메모리 영역에 접근하는 것이 원천적으로 차단된다. 또한 커널 자체의 메모리 공간도 보호되어, 하나의 잘못된 프로그램이 시스템 전체를 불안정하게 만드는 것을 방지한다.13
• 더 큰 주소 공간: 프로세스는 실제 물리 RAM보다 훨씬 큰 프로그램을 실행할 수 있다. 프로그램의 모든 부분이 동시에 메모리에 올라와 있을 필요가 없기 때문이다.2
• 메모리 효율성: 여러 프로세스가 공통으로 사용하는 라이브러리(예: 표준 C 라이브러리)의 경우, 물리 메모리에는 단 하나의 복사본만 올려두고, 각 프로세스의 가상 주소 공간에서 이 동일한 물리 메모리 영역을 가리키도록 매핑할 수 있다. 이를 통해 상당한 양의 메모리를 절약할 수 있다.30

이러한 가상 메모리 관리의 복잡성은 사용자에게는 완전히 감춰져 있다. 개발자는 마치 자신의 프로그램이 거대하고 독점적인 메모리 공간을 사용하는 것처럼 코드를 작성할 수 있으며, 실제 물리 메모리를 할당하고 관리하는 모든 작업은 커널이 투명하게 처리한다. 이는 메모리 관리를 하나의 정교한 ’착각의 게임’으로 볼 수 있다. 가상 메모리는 거대한 전용 공간의 착각을, 요구 페이징은 프로그램 전체가 메모리에 로드된 착각을, 캐싱은 느린 디스크가 빠른 것처럼 보이는 착각을 만들어낸다. 커널의 역할은 이러한 착각들을 효율적이고 끊김 없이 유지하는 것이다.

5.2 하드웨어 지원 번역: MMU와 페이지 테이블

가상 주소를 실제 물리 주소로 변환하는 작업은 순수하게 소프트웨어만으로 처리하기에는 너무 느리다. 따라서 이 과정은 CPU 내에 탑재된 ’메모리 관리 장치(Memory Management Unit, MMU)’라는 특수한 하드웨어의 도움을 받아 수행된다.29

커널은 각 프로세스를 위해 ’페이지 테이블(Page Table)’이라는 자료구조를 생성하고 관리한다.29 페이지 테이블은 가상 주소 공간을 ’페이지(Page)’라는 고정된 크기(보통 4KB)의 블록으로 나누고, 물리 메모리는 ’프레임(Frame)’이라는 동일한 크기의 블록으로 나누어, 어떤 가상 페이지가 어떤 물리 프레임에 매핑되는지에 대한 정보를 담고 있다. 프로세스가 특정 가상 주소에 접근하면, MMU는 해당 주소를 페이지 번호(Page Number)와 페이지 내 오프셋(Offset)으로 분리한다. 그 후, 페이지 번호를 인덱스로 사용하여 현재 프로세스의 페이지 테이블을 조회하고, 매핑된 물리 프레임 번호를 찾아낸다. 마지막으로 이 프레임 번호에 오프셋을 더하여 최종적인 물리 주소를 계산한다.29

이 변환 과정의 속도를 높이기 위해, MMU는 ’변환 색인 버퍼(Translation Lookaside Buffer, TLB)’라는 고속 캐시를 사용한다.29 TLB는 최근에 사용된 가상-물리 주소 변환 정보(페이지 테이블 엔트리)를 저장한다. MMU가 주소 변환을 시도할 때, 먼저 TLB를 확인하여 원하는 정보가 있으면(TLB Hit), 느린 메인 메모리의 페이지 테이블까지 접근할 필요 없이 즉시 물리 주소를 얻을 수 있다. 정보가 없으면(TLB Miss) MMU는 페이지 테이블을 직접 참조하고, 그 결과를 TLB에 새로 저장한다. 이처럼 현대 운영체제의 메모리 관리는 하드웨어(MMU, TLB)와 소프트웨어(커널의 페이지 테이블 관리 및 예외 처리)가 긴밀하게 협력하는 공동 설계 시스템의 전형적인 예이다. 커널은 하드웨어가 사용할 자료구조를 설정하고, 하드웨어는 변환에 실패했을 때 예외를 발생시켜 다시 소프트웨어에게 제어권을 넘긴다.

5.3 규모의 문제: 다단계 페이지 테이블

32비트 시스템에서 4KB 페이지를 사용하는 경우를 가정해 보자. 전체 4GB의 가상 주소 공간을 매핑하기 위해서는 약 100만 개(220)의 페이지 테이블 엔트리가 필요하다. 각 엔트리가 4바이트라고 하면, 프로세스 하나당 페이지 테이블의 크기만 4MB에 달한다.29 대부분의 프로세스는 이 광대한 주소 공간의 극히 일부만 사용하므로, 단일 페이지 테이블을 사용하는 것은 엄청난 메모리 낭비이다.35

리눅스는 이 문제를 해결하기 위해 ‘다단계 페이지 테이블(Multi-level Page Table)’ 또는 ‘계층적 페이징(Hierarchical Paging)’ 기법을 사용한다.31 32비트 시스템에서는 보통 2단계, 64비트 시스템에서는 3단계 또는 4단계 구조가 사용된다. 예를 들어 2단계 페이징에서는, 가상 주소의 상위 비트들이 ’페이지 디렉토리(Page Directory)’라는 최상위 테이블의 인덱스로 사용된다. 페이지 디렉토리의 각 엔트리는 ’페이지 테이블’의 주소를 가리킨다. 가상 주소의 중간 비트들이 이 페이지 테이블의 인덱스로 사용되어 최종적으로 물리 프레임의 주소를 찾게 된다. 이 구조의 핵심적인 장점은, 만약 프로세스가 특정 거대한 주소 영역(예: 2MB)을 전혀 사용하지 않는다면, 페이지 디렉토리에서 해당 영역을 가리키는 엔트리를 그냥 NULL로 설정하면 된다는 것이다. 이렇게 하면 그 영역에 해당하는 하위 페이지 테이블 전체(수백 개의 엔트리)를 위한 메모리를 할당할 필요가 없어진다.35 이를 통해 페이지 테이블이 차지하는 메모리 공간을 획기적으로 줄일 수 있다.

5.4 부족함에 대한 대처: 요구 페이징, 페이지 폴트, 스와핑

리눅스는 ‘요구 페이징(Demand Paging)’ 기법을 사용하여 메모리 효율성을 극대화한다. 이는 프로세스가 시작될 때 프로그램의 모든 부분을 메모리에 올리는 것이 아니라, 특정 페이지가 실제로 접근될 때(즉, ’요구’될 때) 비로소 디스크에서 메모리로 해당 페이지를 가져오는 방식이다.31

• 페이지 폴트 (Page Fault): 프로세스가 접근하려는 가상 주소에 해당하는 페이지가 현재 물리 메모리에 존재하지 않을 경우(즉, 페이지 테이블에 유효한 매핑 정보가 없을 경우), MMU는 ’페이지 폴트’라는 예외(exception)를 발생시켜 CPU의 제어권을 커널에게 넘긴다.30
• 페이지 폴트 처리: 커널의 페이지 폴트 핸들러가 활성화된다. 핸들러는 먼저 해당 접근이 유효한지(예: 권한을 위반한 접근이 아닌지) 검사한다. 유효한 접근이라면, 커널은 디스크(실행 파일 또는 스왑 영역)에서 필요한 데이터가 어디에 있는지 찾아낸다. 그 후, 비어있는 물리 프레임을 하나 할당받아 디스크로부터 데이터를 읽어들인다. 마지막으로, 페이지 테이블을 업데이트하여 새로운 가상-물리 매핑을 생성하고, 원래 명령을 다시 실행하도록 하여 프로세스를 재개시킨다.30
• 스와핑 (Swapping): 만약 페이지 폴트가 발생했는데 가용한 빈 물리 프레임이 없다면, 커널은 메모리 공간을 확보하기 위해 기존에 있던 페이지 중 하나를 디스크로 쫓아내야 한다. 이 과정을 ‘스와핑’ 또는 ’페이지 아웃(page out)’이라고 한다.30 리눅스는 어떤 페이지를 희생시킬지 결정하기 위해 ‘최근 최소 사용(Least Recently Used, LRU)’ 알고리즘의 근사치를 사용한다. 즉, 가장 오랫동안 참조되지 않은 페이지를 교체 대상으로 선택하는 것이다.30 만약 쫓겨나는 페이지가 메모리에 올라온 후 내용이 변경되었다면(이런 페이지를 ’더티 페이지(dirty page)’라고 한다), 그 내용을 디스크의 특별한 공간인 ’스왑 공간(swap space)’에 안전하게 저장한 후에야 해당 프레임을 재사용할 수 있다.2

5.5 커널 메모리 캐시

디스크 I/O는 매우 느린 작업이므로, 리눅스는 성능 향상을 위해 여러 수준의 캐시를 적극적으로 활용한다.

• 페이지 캐시 (Page Cache): 디스크로부터 읽어온 파일의 내용을 메모리에 캐싱하는 데 사용된다. 어떤 프로세스가 파일을 읽으면, 해당 파일의 페이지들은 페이지 캐시에 저장된다. 이후 다른 프로세스가 동일한 파일의 동일한 부분을 읽으려고 하면, 커널은 느린 디스크에 다시 접근할 필요 없이 페이지 캐시에서 직접 데이터를 빠르게 제공할 수 있다. 이는 리눅스 시스템의 I/O 성능을 좌우하는 가장 중요한 메커니즘 중 하나이다.31
• 버퍼 캐시 (Buffer Cache): 파일 시스템 수준이 아닌, 물리적인 디스크 블록 단위의 데이터를 캐싱한다. 역사적으로 페이지 캐시와 분리되어 있었지만, 현대 리눅스에서는 대부분 페이지 캐시에 통합되어 운영된다. 이는 블록 장치에 대한 I/O를 캐싱하는 역할을 한다.33
• 스왑 캐시 (Swap Cache): 스왑 아웃된 페이지를 캐싱한다. 어떤 페이지가 스왑 아웃되어 디스크에 저장된 후, 물리 메모리에서도 제거되기 전에 잠시 스왑 캐시에 남아있을 수 있다. 만약 이 페이지가 다시 필요해지면, 디스크에서 다시 읽어올 필요 없이 스왑 캐시에서 빠르게 복구할 수 있다. 또한, 변경되지 않은(clean) 페이지를 다시 스왑 아웃해야 할 때, 이미 스왑 파일에 동일한 내용이 존재한다면 불필요한 디스크 쓰기 작업을 생략할 수 있게 해준다.33

6. 가상 파일 시스템 (VFS): 데이터에 대한 통일된 관점

6.1 VFS 추상화 계층

리눅스 커널의 또 다른 위대한 설계 중 하나는 ‘가상 파일 시스템(Virtual File System, VFS)’ 또는 ’가상 파일 시스템 스위치(Virtual Filesystem Switch)’라 불리는 추상화 계층이다.38 VFS는 사용자 공간의 응용 프로그램들이 파일 시스템의 종류에 관계없이 일관된 시스템 호출(예: open(), read(), write(), close())을 사용하여 파일에 접근할 수 있도록 해주는 핵심적인 소프트웨어 계층이다.11 VFS 덕분에 리눅스는 ext4, XFS, Btrfs와 같은 네이티브 파일 시스템뿐만 아니라, Windows의 NTFS, macOS의 HFS+, 그리고 NFS와 같은 네트워크 파일 시스템까지 수많은 종류의 파일 시스템을 동시에 마운트하고 매끄럽게 사용할 수 있다.10 사용자 입장에서는 이 모든 것이 단일한 계층 구조의 디렉터리 트리로 보일 뿐, 그 아래에 얼마나 다양한 파일 시스템이 연결되어 있는지 전혀 알 필요가 없다.40

6.2 공통 파일 모델: 네 가지 핵심 VFS 객체

VFS가 이러한 강력한 추상화를 달성하는 비결은 ’공통 파일 모델(Common File Model)’에 있다. 이 모델은 C언어로 구현되었지만, 객체 지향 설계 사상을 차용하여 모든 파일 시스템을 표현할 수 있는 네 가지 핵심 자료구조(객체)를 정의한다.38

• superblock 객체: 마운트된 개별 파일 시스템 전체를 표현하는 객체이다. 파일 시스템의 종류, 블록 크기, 마운트 옵션, 그리고 해당 파일 시스템의 루트 디렉터리를 가리키는 포인터 등과 같은 최상위 메타데이터를 저장한다.38 시스템에 파일 시스템이 마운트될 때마다 하나의

superblock 객체가 메모리에 생성된다.

• inode 객체: 디스크 상의 특정 파일이나 디렉터리 하나를 표현하는 객체이다. 파일의 이름과 실제 데이터를 제외한 모든 메타데이터, 즉 파일 종류, 접근 권한, 소유자 정보, 파일 크기, 생성 및 수정 시간, 그리고 데이터 블록을 가리키는 포인터 목록 등을 담고 있다.38

여기서 중요한 점은 VFS의 inode 객체는 메모리 상의 자료구조이며, ext4와 같은 실제 파일 시스템이 디스크에 저장하는 inode와는 구별된다는 것이다.43 커널이 파일에 접근할 때, 디스크의 inode 정보를 읽어와 메모리에 VFS

inode 객체를 생성하고 채운다.

• dentry (디렉터리 엔트리) 객체: 파일 이름과 그에 해당하는 inode를 연결하는 역할을 한다. 즉, 경로(path)의 각 구성 요소를 표현한다. 예를 들어, /home/user/file.txt라는 경로는 ‘/’, ‘home’, ‘user’, ’file.txt’라는 네 개의 dentry 객체로 해석된다. dentry는 디스크에 저장되는 구조가 아니라, 경로명 탐색 속도를 높이기 위해 커널이 메모리에서 동적으로 생성하고 관리하는 캐시 객체이다. 자주 접근하는 경로의 dentry들은 ’덴트리 캐시(dentry cache)’에 저장되어, 반복적인 디스크 접근을 피하고 빠른 경로 탐색을 가능하게 한다.38

• file 객체: 프로세스에 의해 열린(open) 파일을 표현하는 객체이다. 사용자가 open() 시스템 호출을 하면 커널은 이 file 객체를 생성하여 프로세스에게 파일 디스크립터(file descriptor)를 반환한다. 이 객체는 해당 프로세스가 파일을 어떤 모드(읽기/쓰기)로 열었는지, 그리고 파일 내에서 현재 어디를 읽거나 쓰고 있는지(파일 오프셋)와 같은 정보를 추적한다.38 이 덕분에 여러 프로세스가 동일한 파일을 동시에 열더라도, 각자 다른 위치에서 독립적으로 파일 작업을 수행할 수 있다.

이러한 VFS의 설계는 C언어와 같은 절차적 언어 내에서 객체 지향 원리(추상화, 다형성)를 구현한 탁월한 사례이다. VFS는 inode, file 등 추상화된 ’객체’를 정의하고, 각 객체는 operations라는 함수 포인터 테이블을 가진다. 실제 파일 시스템(예: ext4)은 이 테이블을 자신의 구체적인 함수들로 채워 넣는다. VFS 코드는 이 추상화된 인터페이스(예: file->f_op->read())를 호출할 뿐이지만, 실제로는 다형성에 의해 ext4의 read 함수가 실행된다. 이는 새로운 파일 시스템을 추가할 때 VFS의 핵심 코드를 수정할 필요 없이, 단지 새로운 operations 세트를 구현하여 등록하기만 하면 되므로 엄청난 확장성을 제공한다.

6.3 VFS의 작동 방식: 시스템 호출과 오퍼레이션

VFS의 작동 메커니즘은 시스템 호출과 operations 구조체의 연동을 통해 이루어진다.

1. 사용자 프로세스가 read()와 같은 파일 관련 시스템 호출을 실행하면, 제어권이 커널로 넘어와 VFS 계층이 이 요청을 받는다.38
2. VFS는 프로세스가 전달한 파일 디스크립터를 통해 해당 요청이 어떤 file 객체와 연관되어 있는지 파악한다.
3. file 객체는 file_operations라는 구조체를 가리키는 포인터(f_op)를 가지고 있다. 이 구조체는 read, write, open, release 등 파일에 수행될 수 있는 모든 연산에 대한 함수 포인터들의 집합이다.38
4. VFS는 이 file_operations 테이블에서 해당 연산(이 경우 read)에 해당하는 함수 포인터를 찾아 호출한다.
5. 이 함수 포인터는 파일이 처음 열릴 때, 해당 파일이 속한 실제 파일 시스템(예: ext4, NTFS)에 의해 자신의 구체적인 read 함수 주소로 설정되었다.
6. 결과적으로, VFS의 일반적인 read 요청은 실제 파일 시스템의 특화된 read 함수로 전달(dispatch)되어 실행된다.10

이러한 메커니즘을 통해 VFS는 ‘어떻게’ 파일을 읽을지에 대한 구체적인 내용은 알지 못한 채, 단지 ’읽으라’는 명령을 하달하는 중재자 역할만을 수행한다. 실제 작업은 각 파일 시스템이 알아서 처리한다.

6.4 장치 드라이버와의 상호작용

리눅스의 “모든 것은 파일이다(everything is a file)“라는 설계 철학은 VFS를 통해 장치(device)에까지 확장된다.46 키보드, 마우스, 하드 디스크, 직렬 포트와 같은 모든 하드웨어 장치들은 /dev 디렉터리 내의 특수 파일(special file) 형태로 사용자 공간에 노출된다 (예: /dev/sda1, /dev/tty0).10

사용자 프로그램은 이 장치 파일을 일반 파일처럼 open(), read(), write() 할 수 있다. 이 요청 역시 VFS를 통해 처리된다. 해당 장치를 위한 장치 드라이버는 VFS가 요구하는 file_operations 구조체를 구현하여 커널에 등록한다.46 사용자가 /dev/tty0에 데이터를 write()하면, VFS는 tty 드라이버가 등록한 write 함수를 호출하고, 이 함수가 실제로 직렬 포트 하드웨어에 데이터를 전송하는 것이다. 이처럼 VFS는 파일 시스템뿐만 아니라 장치 드라이버까지 아우르는, 시스템 I/O 전반에 대한 통일된 추상화 인터페이스를 제공한다.

7. 커널 생태계: 전 지구적 협업의 장

7.1 개발 계층 구조: 부관을 둔 자애로운 독재자

리눅스 커널 개발은 거대하고 분산되어 있지만, 명확한 계층 구조를 통해 질서 있게 운영된다. 이 구조는 종종 ‘자애로운 종신 독재자(Benevolent Dictator for Life)’ 모델로 묘사된다.

• 리누스 토르발스 (Linus Torvalds): 개발 계층의 정점에 있으며, 어떤 코드가 최종적으로 메인라인(mainline) 커널에 포함될지를 결정하는 최종적인 권한을 가진다.47 그는 특정 코드의 기술적 세부사항보다는 전체적인 개발 방향과 커널의 장기적인 건전성을 관리하는 역할을 한다.
• 메인테이너 (Maintainers): 각 서브시스템(예: 네트워킹, 스토리지, ARM 아키텍처 등)을 책임지는 신뢰받는 소수의 최고 개발자들이다.47 이들은 자신의 담당 영역에 제출되는 수많은 패치(코드 변경 제안)를 검토하고, 테스트하며, 승인 또는 거부하는 1차적인 게이트키퍼 역할을 한다. 이들은 잘 정리되고 검증된 패치 묶음을 개발 주기 중 ‘머지 윈도우(merge window)’ 기간에 리누스 토르발스에게 제출한다.47 그레그 크로아-하트만(Greg Kroah-Hartman)과 같은 핵심 메인테이너들은 안정 버전(stable version) 관리를 책임지며 생태계에서 중추적인 역할을 한다.4
• 기여자 (Contributors): 전 세계 수천 명의 개인 개발자 및 기업 소속 엔지니어들로, 실제 코드를 작성하고, 버그를 수정하며, 개선안을 제안하는 가장 광범위한 그룹이다.47 이들은 자신의 패치를 관련 서브시스템의 메일링 리스트에 제출하고, 메인테이너와 다른 리뷰어들의 피드백을 받아 코드를 개선하는 과정을 거친다.

이러한 개발 프로세스는 단순히 코드의 기술적 우수성뿐만 아니라, 전 세계 수천 명의 기여를 체계적으로 통합하고 품질을 유지하는 사회적, 관리적 시스템의 정수라 할 수 있다. 즉, 리눅스 커널의 성공은 코드 자체뿐만 아니라 이 정교한 개발 프로세스라는 ‘제품’ 덕분이기도 하다.

7.2 개발 라이프사이클: 리드미컬한 주기

리눅스 커널 개발은 매우 규칙적이고 예측 가능한 주기를 따른다.

• 메인라인 커널 (Mainline Kernel): 리누스 토르발스가 직접 관리하는 주 개발 브랜치이다.48 모든 새로운 기능은 여기에 가장 먼저 통합된다.
• 머지 윈도우 (Merge Window): 새로운 버전(예: 6.8)이 릴리스된 직후, 약 2주간의 ’머지 윈도우’가 열린다. 이 기간 동안 각 서브시스템 메인테이너들은 다음 버전(예: 6.9)에 포함될 새로운 기능과 주요 변경 사항들을 리누스에게 제출한다.48
• 릴리스 후보 (Release Candidates, rc): 머지 윈도우가 닫히면, 새로운 기능 추가는 중단되고 안정화 단계에 들어간다. 리누스는 약 일주일 간격으로 rc1, rc2,… 와 같은 릴리스 후보 버전을 내놓는다. 이 기간 동안 개발자 커뮤니티는 광범위한 테스트를 통해 버그를 찾아 수정하는 데 집중한다.
• 안정(Stable) 및 장기 지원(LTS) 브랜치: 메인라인 버전이 최종적으로 릴리스되면, 해당 버전의 유지보수는 그레그 크로아-하트만과 같은 안정 브랜치 메인테이너에게 넘어간다. 이들은 중요한 버그 수정이나 보안 패치를 이전 버전들에 적용(backport)하여 안정 버전을 주기적으로 릴리스한다.13 특정 버전들은 ‘장기 지원(Long-Term Support, LTS)’ 버전으로 지정되어, 수년간(2년 이상) 유지보수를 제공받는다.13 이는 안정성이 최우선인 기업 환경이나 임베디드 제품 개발에 매우 중요하다.

7.3 법적 기반: GNU GPLv2

리눅스 커널에 기여되는 모든 코드는 반드시 GNU GPL 버전 2와 호환되는 라이선스 하에 배포되어야 한다.48 GPLv2는 리눅스 생태계를 지탱하는 법적, 철학적 기반이며 다음과 같은 중요한 특징을 가진다.

• 자유의 보장: GPLv2는 누구든지 소스 코드를 보고, 수정하고, 재배포할 자유를 보장한다. 또한, 커널을 수정한 파생 저작물 역시 동일한 GPLv2 라이선스로 소스 코드를 공개해야 할 의무를 부과한다. 이는 특정 기업이 리눅스 코드를 가져가 독점적인 개선을 한 뒤 소스를 공개하지 않고 비공개 제품으로 만드는 것을 방지하는 강력한 ‘카피레프트(copyleft)’ 조항이다.
• 분산된 저작권: 커널에 코드를 기여하더라도, 개발자는 자신의 저작권을 중앙 기관에 양도하지 않고 그대로 보유한다.48 따라서 리눅스 커널은 수천 명의 저작권 소유자가 존재하는 형태가 된다. 이 구조는 커널의 라이선스를 변경하는 것을 사실상 불가능하게 만든다. 라이선스를 변경하려면 모든 저작권자의 동의가 필요하기 때문이다. 이처럼 GPLv2 라이선스를 변경하기 어렵다는 점은 역설적으로 법적 안정성을 제공한다. 기업들은 리눅스 커널의 라이선스 규칙이 갑자기 바뀔 위험이 없다는 확신 하에 수십억 달러 규모의 장기적인 연구개발 투자를 할 수 있다.

7.4 상업적 생태계: 협력과 경쟁의 공존

리눅스 생태계는 순수한 자원봉사자들의 커뮤니티를 넘어, 치열한 경쟁 관계에 있는 글로벌 기업들이 공존하며 협력하는 독특한 ’협력적 경쟁(co-opetition)’의 장이다. 레드햇, 구글, 인텔, 삼성, IBM과 같은 거대 기술 기업들은 리눅스 커널의 최대 기여자 그룹에 속한다. 이들은 자사 제품과 서비스의 기반이 되는 커널의 발전을 위해 엔지니어들을 고용하여 커널 개발에 직접 참여시킨다.

이 생태계에는 특정 칩셋을 위한 드라이버와 BSP(Board Support Package)를 개발하는 SoC 벤더(퀄컴, 엔비디아, 브로드컴 등)와, 이들의 결과물을 받아 스마트폰, 자동차, 가전제품 등 최종 제품을 만드는 OEM(Original Equipment Manufacturer) 업체들이 복잡하게 얽혀 있다.47 이들은 시장에서는 경쟁자이지만, 모두가 의존하는 공통의 기반인 리눅스 커널의 발전을 위해서는 협력해야만 하는 구조이다. 이러한 상업적 참여는 커널 개발에 막대한 자원과 인력을 투입하게 하여, 리눅스가 빠르게 변화하는 기술 환경에 지속적으로 적응하고 발전할 수 있는 원동력이 된다.

8. 현대 커널의 비교 분석

8.1 리눅스 대 Windows NT 커널

리눅스와 Windows NT 커널은 현대 운영체제를 대표하는 양대 산맥이지만, 그 내부 구조와 설계 철학은 근본적인 차이를 보인다.

• 아키텍처: 앞서 논의했듯이 리눅스는 모듈형 모놀리식 커널이다.6 반면 Windows NT 커널은 공식적으로 **하이브리드 커널(Hybrid Kernel)**로 분류된다.49 NT 커널은 마이크로커널과 유사하게 핵심 기능(HAL - Hardware Abstraction Layer, 커널 코어)을 최소화하려 시도했지만, 성능상의 이유로 파일 시스템, 객체 관리자, 그래픽 하위 시스템(Win32k.sys)과 같은 전통적인 운영체제 서비스들을 여전히 커널 모드에서 실행한다. 이는 순수한 마이크로커널보다는 모놀리식에 가깝지만, 리눅스보다는 더 명확하게 계층화된 구조를 가진다.

• 설계 철학: 리눅스가 전통적인 유닉스의 “모든 것은 파일이다“라는 철학을 계승한 반면, NT 커널은 처음부터 **객체 지향(Object-Oriented)**적으로 설계되었다.49 NT 내부에서 프로세스, 스레드, 파일, 세마포어 등 모든 시스템 자원은 ’객체(Object)’로 취급되며, 이 모든 객체는 중앙의 ’객체 관리자(Object Manager)’에 의해 생성 및 관리된다. 이 통합된 객체 모델은 접근 제어, 명명(naming), 자원 추적 등을 위한 일관된 메커니즘을 제공한다.49 이는 파일이라는 단일 추상화에 많은 것을 의존하는 리눅스의 VFS보다 더 형식적이고 구조화된 접근 방식이다. 예를 들어, 리눅스는

/proc, /sys와 같은 가상 파일 시스템을 통해 비-파일 객체(프로세스 정보, 시스템 상태 등)를 파일처럼 보이게 만들지만, NT에서는 이 모든 것이 객체 트리의 일부로 자연스럽게 표현된다.10

• 프로세스 모델: 유닉스/리눅스에서 프로세스는 init 프로세스로부터 이어지는 엄격한 부모-자식 계층 구조를 형성한다.49 그러나 NT에는 이러한 고유한 계층 관계가 없다. 프로세스는 생성자로부터 자원을 ’상속’받을 수는 있지만, 생성된 후에는 완전히 독립적인 개체로 존재한다.49

• 드라이버 모델: NT의 드라이버 모델(Windows Driver Model, WDM 및 후속 모델)은 매우 계층적이고 엄격하게 정의되어 있다. 이는 초기 Windows 9x 시절, 불안정한 서드파티 드라이버가 시스템 전체를 다운시키는 문제를 해결하기 위한 직접적인 대응의 결과물이다.49 리눅스의 드라이버 모델은 상대적으로 더 유연하지만, 역사적으로는 덜 엄격하게 정의되어 있다는 평가를 받았다.

8.2 리눅스 대 XNU (macOS/iOS 커널)

Apple의 macOS와 iOS의 심장인 XNU 커널 역시 리눅스와는 다른 진화의 길을 걸어왔다.

• 아키텍처: XNU는 NT 커널보다 더 학술적인 의미의 하이브리드 커널이다.50 XNU는 카네기 멜런 대학에서 개발한

Mach 마이크로커널과 FreeBSD 모놀리식 커널의 구성 요소를 명시적으로 결합한 구조이다. Mach는 기본적인 프로세스 간 통신(IPC), 가상 메모리 관리, 스케줄링과 같은 가장 낮은 수준의 서비스를 제공한다. 그 위에 FreeBSD로부터 가져온 코드 계층이 올라가 POSIX API 호환성, 가상 파일 시스템(VFS), 네트워킹 스택, 보안 정책 등 더 높은 수준의 유닉스 서비스를 제공한다.50

• 구성 요소: XNU는 크게 세 부분으로 구성된다: Mach, BSD, 그리고 드라이버 개발을 위한 C++ 기반 프레임워크인 IOKit.50 이처럼 명확하게 구분된 구성 요소들의 조합은 순수한 모놀리식인 리눅스와는 뚜렷한 대조를 이룬다.

• 개발 유산: 리눅스가 처음부터 새롭게 작성된(from scratch) 커널인 반면, XNU는 이미 존재하던 두 개의 다른 커널 프로젝트(학술적 연구의 산물인 Mach와, 검증된 유닉스인 BSD)를 융합하여 만들어졌다. 이로 인해 두 커널은 사용자에게 유사한 POSIX 호환 환경을 제공하더라도, 내부적인 구현 방식과 철학에서 상당한 차이를 보인다.

8.3 성능, 유연성, 그리고 설계의 트레이드오프

세 커널은 모두 유닉스라는 공통의 조상에서 출발했지만, 각기 다른 진화 경로를 택했다. 리눅스는 전통적인 모놀리식 모델을 유지하고 LKM으로 유연성을 더하며 성능을 극대화하는 실용적인 길을 선택했다. NT는 과거와의 단절을 선언하며 안정성과 보안을 위한 새로운 객체 지향 하이브리드 모델을 추구했다. XNU는 기존의 검증된 오픈소스 자산(Mach, BSD)을 결합하여 안정성과 유닉스 호환성을 동시에 확보하는 하이브리드 방식을 택했다.

성능 면에서, 리눅스의 가볍고 효율적인 모놀리식 설계는 종종 원시적인 컴퓨팅 및 I/O 벤치마크에서 Windows를 능가하는 결과를 보여준다.51 NT의 정교한 객체 모델은 설계적으로는 우아하지만, 추가적인 추상화 계층으로 인한 오버헤드가 성능에 영향을 미칠 수 있다는 비판을 받아왔다.49 유연성과 적응성 측면에서는, 리눅스의 완전한 오픈소스 특성과 방대한 커뮤니티, 그리고 LKM 시스템이 결합되어 Windows나 macOS의 폐쇄적인 생태계보다 훨씬 넓은 하드웨어 지원과 다양한 환경으로의 이식성을 가능하게 했다. 결국, 어떤 아키텍처가 절대적으로 우월하다고 말하기는 어렵다. 각 설계는 그 운영체제가 목표로 하는 시장, 개발 철학, 그리고 역사적 배경이 반영된 트레이드오프의 결과물이다.

9. 미래 방향성과 지속적인 도전

9.1 Rust 통합: 메모리 안전성을 향한 패러다임 전환

리눅스 커널의 미래를 논할 때 가장 뜨거운 감자는 단연 ‘Rust’ 언어의 도입이다. 이는 단순한 기술적 논의를 넘어, 커널의 정체성과 개발 문화를 둘러싼 거대한 논쟁으로 비화하고 있다.

• 도입 근거: 지난 수십 년간 리눅스 커널에서 발견된 수많은 보안 취약점(CVE)과 심각한 버그의 상당수는 C 언어의 본질적인 한계, 즉 ‘메모리 안전성(memory safety)’ 문제에서 비롯되었다.52 버퍼 오버플로우, 해제 후 사용(use-after-free), 널 포인터 역참조와 같은 오류들은 C 언어에서는 개발자의 세심한 주의에만 의존해야 하지만, 이는 인간의 실수를 원천적으로 막을 수 없다. Rust는 ’소유권(ownership)’과 ’대여 검사기(borrow checker)’라는 독창적인 컴파일 타임 메커니즘을 통해, 가비지 컬렉터 없이도 이러한 종류의 메모리 오류를 원천적으로 방지하도록 설계된 현대적인 시스템 프로그래밍 언어이다.54 따라서 커널에 Rust를 도입하자는 주장의 핵심은, 새로운 코드, 특히 보안에 민감한 장치 드라이버 등을 Rust로 작성함으로써 커널의 전반적인 보안과 안정성을 획기적으로 향상시키자는 것이다.52
• 논쟁과 커뮤니티의 갈등: Rust 도입은 커널 커뮤니티 내에서 극심한 의견 대립을 낳고 있다.
• 찬성 측: Rust 도입을 지지하는 개발자들은 이것이 고질적인 메모리 버그를 퇴치하고 커널을 현대화하는 필수적인 진화 과정이라고 주장한다. 또한, C/C++에 익숙하지 않은 젊은 개발자들이 Rust를 통해 커널 개발에 더 쉽게 참여할 수 있게 하여 개발자 커뮤니티의 고령화 문제를 해결할 수 있다고 본다.53
• 반대 측: 반면, 오랫동안 C 언어로 커널을 유지보수해 온 일부 핵심 메인테이너들은 강한 우려를 표명한다. 이들은 C와 Rust가 혼재하는 다중 언어 코드베이스가 가져올 복잡성, 추가적인 유지보수 부담, 그리고 30년간 유지되어 온 커널의 단순성과 일관성을 해칠 수 있다고 지적한다.57 한 메인테이너는 Rust 코드가 C 코드와 상호작용하기 위해 추가되는 추상화 계층을 ’암적인 요소(cancer-like thing)’라고 표현하며, 이는 결국 두 개의 다른 커뮤니티가 두 개의 다른 코드베이스를 유지하는 것과 같은 파편화를 초래할 것이라고 경고했다.58 이 논쟁은 기술적 차원을 넘어 세대 간, 문화 간의 갈등 양상으로 번졌으며, 일부 개발자들이 논쟁에 지쳐 사임하는 사태까지 발생했다.59
• 현재 상황: 현재 리눅스 커널에서 Rust 지원은 실험적인 옵션으로 포함되어 있다. 리누스 토르발스는 신중하게 “두고 보자“는 입장을 취하고 있으며, 전면적인 전환보다는 드라이버와 같은 독립적인 부분에서 점진적으로 시도해보는 방향으로 논의가 진행 중이다.62 이 논쟁은 단순히 언어 선택의 문제를 넘어, 커널이 미래의 도전에 어떻게 적응할 것인지, 그리고 변화를 수용하는 과정에서 커뮤니티의 분열을 어떻게 관리할 것인지에 대한 리트머스 시험지 역할을 하고 있다.

9.2 지속적인 보안 위협: 실제 취약점 사례 분석

리눅스 커널의 보안은 이론적인 논의가 아닌, 끊임없이 발생하는 실제 공격과 방어의 연속이다. 최근의 몇 가지 주요 취약점 사례는 커널이 직면한 위협의 심각성과 본질을 명확히 보여준다.

• 사례 1: Dirty Pipe (CVE-2022-0847): 이 취약점은 리눅스의 파이프(pipe) 메커니즘에 존재하던 미묘한 버그를 악용한 로컬 권한 상승 취약점이다. 공격자는 시스템의 일반 사용자 권한만으로 읽기 전용으로 설정된 파일을 포함하여 시스템의 모든 파일에 임의의 데이터를 덮어쓸 수 있었다.64 이는 /etc/passwd 파일을 수정하여 루트 권한을 탈취하거나, 시스템 핵심 바이너리를 악성 코드로 교체하는 등의 심각한 공격으로 이어질 수 있었다. Dirty Pipe는 커널의 핵심 서브시스템에 존재하는 작은 논리적 결함이 어떻게 시스템 전체의 보안을 무너뜨릴 수 있는지를 보여주는 대표적인 사례이다.

• 사례 2: OverlayFS 취약점 (예: CVE-2023-0386): OverlayFS는 컨테이너 기술 등에서 널리 사용되는 파일 시스템 계층이다. 이 서브시스템에서는 권한 검증 누락으로 인한 권한 상승 취약점이 반복적으로 발견되어 왔다. CVE-2023-0386의 경우, 패치가 공개된 지 2년이 지난 시점에도 여전히 실제 공격에 악용되고 있다는 사실이 보고되었다.65 이는 리눅스 생태계의 구조적인 약점인 ’패치 갭(Patch Gap)’을 드러낸다. 즉, 메인라인 커널에서 패치가 이루어지더라도, 그것이 각 배포판(우분투, 데비안 등)에 적용되고, 최종 사용자가 시스템 재부팅의 부담을 감수하며 실제 시스템에 적용하기까지는 수개월, 심지어 수년이 걸릴 수 있다.65 공격자들은 바로 이 시간적 격차를 집요하게 노린다.

• 사례 3: 최근 고위험 CVE (예: CVE-2024-53104): 최근 미국 사이버 보안 및 인프라 보안국(CISA)은 커널의 범위를 벗어난 쓰기(out-of-bounds write) 취약점인 CVE-2024-53104에 대해 연방 기관에 긴급 패치를 지시했다.66 이는 메모리 안전성 문제로 인한 취약점이 지금 이 순간에도 계속해서 발견되고 있으며, 국가 안보 수준의 위협으로 간주되고 있음을 시사한다.

9.3 AI 시대와 특수 하드웨어의 시대

리눅스 커널은 새로운 도전에 직면해 있다. 인공지능(AI)과 머신러닝의 부상은 GPU, TPU와 같은 AI 가속기 하드웨어에 대한 더 효율적이고 긴밀한 지원을 요구하고 있다. 또한, 사물 인터넷(IoT)과 엣지 컴퓨팅의 확산은 더욱 다양하고 복잡한 SoC(System-on-Chip) 하드웨어에 대한 최적화와 실시간 처리 능력의 중요성을 부각시키고 있다. 커널은 이러한 새로운 하드웨어 패러다임과 워크로드를 효과적으로 지원하기 위해 지속적으로 진화해야 하는 과제를 안고 있다.

10. 결론

10.1 리눅스 커널의 핵심 특성 요약

본 안내서를 통해 분석한 리눅스 커널은 몇 가지 핵심적인 특성으로 요약될 수 있다. 첫째, 실용주의적 설계 철학이다. 모놀리식 아키텍처의 성능과 적재 가능 커널 모듈의 유연성을 결합한 하이브리드적 접근은 이데올로기보다 실용성을 우선시하는 리눅스의 핵심 정신을 보여준다. 둘째, 알고리즘적 우아함이다. CFS 스케줄러의 vruntime과 레드-블랙 트리, 메모리 관리의 다단계 페이지 테이블 등, 커널의 핵심 메커니즘들은 복잡한 문제를 단순하고 효율적인 컴퓨터 과학 원리로 해결하려는 노력이 돋보인다. 셋째, 강력한 추상화 계층이다. 가상 메모리와 가상 파일 시스템(VFS)은 하드웨어의 복잡성을 감추고 개발자에게 일관되고 사용하기 쉬운 인터페이스를 제공함으로써, 리눅스의 광범위한 이식성과 호환성의 기반이 되었다. 마지막으로, 독보적인 개발 모델이다. 전 세계 수천 명의 개발자가 참여하는 거대한 프로젝트를 체계적으로 관리하는 계층적 개발 프로세스와 GPLv2라는 확고한 법적 기반은 기술 자체만큼이나 리눅스 성공의 중요한 요인이다.

10.2 회복탄력성과 미래 전망에 대한 최종 고찰

리눅스 커널이 30년이 넘는 시간 동안 기술 변화의 격랑 속에서 살아남아 번성할 수 있었던 원동력은 그 놀라운 ’회복탄력성(resilience)’과 ’적응력(adaptability)’에 있다. 초기의 단순한 커널에서 시작하여 서버, 모바일, 임베디드, 클라우드, 슈퍼컴퓨터에 이르기까지 모든 컴퓨팅 영역을 아우르도록 진화해 온 과정 자체가 이를 증명한다. 이제 커널은 Rust 도입이라는 또 다른 거대한 변화의 기로에 서 있다. 이 논쟁은 커널이 단순한 코드의 집합이 아니라, 살아있는 사회적 유기체임을 보여준다. 따라서 리눅스 커널의 미래는 단순히 기술적인 도전 과제(보안 강화, 새로운 하드웨어 지원 등)를 어떻게 해결하는지에만 달려있지 않다. 그보다는 커뮤니티 내의 문화적, 세대적 갈등을 어떻게 관리하고, 변화를 수용하며, 협업의 정신을 유지해 나갈 수 있는지에 대한 사회적 능력에 더 크게 좌우될 것이다. 리눅스의 가장 위대한 힘은 코드 라인에 있는 것이 아니라, 그 코드를 함께 만들어가는 사람들의 생태계에 있기 때문이다.

11. 참고 자료

1. 리눅스 커널(Linux kernel)이란 - 개념, 구성요소, 인터페이스 - Red Hat, accessed July 8, 2025, https://www.redhat.com/ko/topics/linux/what-is-the-linux-kernel
2. 리눅스 커널(kernel) - velog, accessed July 8, 2025, https://velog.io/@attosisss_/%EB%A6%AC%EB%88%85%EC%8A%A4-%EC%BB%A4%EB%84%90kernel
3. [OS] 커널(Kernel)이란 - 프로그래민 ‍ - 티스토리, accessed July 8, 2025, https://minkwon4.tistory.com/295
4. 리눅스 - 위키백과, 우리 모두의 백과사전, accessed July 8, 2025, https://ko.wikipedia.org/wiki/%EB%A6%AC%EB%88%85%EC%8A%A4
5. [Linux] 리눅스 커널 분석(IBM) - TOP GUN - 티스토리, accessed July 8, 2025, https://hotpotato.tistory.com/90
6. Linux 커널 및 모듈 공부 기초 - Trillion - 티스토리, accessed July 8, 2025, https://tribal1012.tistory.com/153
7. 운영체제 아키텍처의 종류와 이해 :: 데이즈, accessed July 8, 2025, https://vmilsh.tistory.com/394
8. 모놀리식(Monolithic) kernel과 마이크로(Micro) 커널 - 아는 개발자, accessed July 8, 2025, https://selfish-developer.com/entry/%EB%AA%A8%EB%86%80%EB%A6%AC%EC%8B%9DMonolithic-kernel%EA%B3%BC-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9CMicro-%EC%BB%A4%EB%84%90
9. [Linux Kernel] 커널의 종류(마이크로 커널 & 모놀리식 커널) - Blue-Moon의 정리노트!!, accessed July 8, 2025, https://bluemoon-1st.tistory.com/20
10. Linux/커널 - 나무위키, accessed July 8, 2025, https://namu.wiki/w/Linux/%EC%BB%A4%EB%84%90
11. 리눅스 OS와 서브시스템(논문: Conceptual Architecture of the Linux …, accessed July 8, 2025, https://yonlog.tistory.com/97
12. [리눅스]5. 커널 모듈(Kernel Module) - 대두코기 - 티스토리, accessed July 8, 2025, https://hoohaha.tistory.com/80
13. 리눅스 커널이란?(Linux Kernel) - Somaz의 IT 공부 일지 - 티스토리, accessed July 8, 2025, https://somaz.tistory.com/345
14. Thread와 Process, 그리고 Scheduling - Hooni’s Playground, accessed July 8, 2025, https://hooni-playground.com/1547/
15. Process 와 Thread의 차이 - velog, accessed July 8, 2025, https://velog.io/@yoneeki1177/Process-%EC%99%80-Thread%EC%9D%98-%EC%B0%A8%EC%9D%B4
16. 리눅스 CFS 스케줄러 - 잼잼이의 1인무역 이야기 - 티스토리, accessed July 8, 2025, https://jamcorp6733.tistory.com/201
17. 프로세스 스레드 비교, accessed July 8, 2025, https://hwangtaehyun.github.io/blog/linux/process_thread/
18. process vs thread - 차이점 알아보기 - Navigator Linux Kernel, accessed July 8, 2025, http://navigatorkernel.blogspot.com/2017/01/ch02-process-management2-process-vs.html
19. fork (), vfork (), exec () 및 clone ()의 차이점 (펌) - 만두 보러 오세요 - 티스토리, accessed July 8, 2025, https://netmandoo.tistory.com/45
20. fork vs spawn (그 외 exec, clone 등) - jopemachine. dev blog, accessed July 8, 2025, https://jopemachine.github.io/2022/01/01/Fork-Vs-Spawn-Fork-Exec-Clone/
21. 프로세스 생성 시스템 콜 - fork(), exec() - 2, accessed July 8, 2025, https://probe29.tistory.com/40
22. fork, vfork, clone 차이점과 exec 함수 - Navigator Linux Kernel, accessed July 8, 2025, http://navigatorkernel.blogspot.com/2017/02/process-management5-fork-vfork-clone.html
23. 4. 프로세스 생성 - velog, accessed July 8, 2025, https://velog.io/@sunaookamisiroko/4.-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EC%83%9D%EC%84%B1
24. CSF 스케줄러의 구성요소 - 이것이 점프 투 공작소 - 티스토리, accessed July 8, 2025, https://jaykos96.tistory.com/27
25. CFS 스케줄러 - goodGid - GitHub Pages, accessed July 8, 2025, https://goodgid.github.io/Scheduler-CFS/
26. 리눅스 스케줄러 구현 (CFS) - System Designer, accessed July 8, 2025, https://systemdesigner.tistory.com/86
27. 리눅스커널 - 프로세스 스케줄링 (3) - System Designer - 티스토리, accessed July 8, 2025, https://systemdesigner.tistory.com/19
28. 운영체제 Linux Schedule Algorithm ( O(N), O(1), CFS, 변천사 ), accessed July 8, 2025, https://wpaud16.tistory.com/entry/%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C-Linux-schedule-ON-O1-CFS-%EB%B3%80%EC%B2%9C%EC%82%AC
29. [LInux Kernel] 메모리 관리 : 가상 메모리 - 까망눈 연구소, accessed July 8, 2025, https://jeongzero.oopy.io/359eaa11-b6e6-466c-a066-9ae582c886d4
30. [Linux Kernel] Memory Management - velog, accessed July 8, 2025, https://velog.io/@whattsup_kim/Linux-Kernel-Memory-Management
31. 리눅스 커널 - 메모리 관리 1 - Move Fast - 티스토리, accessed July 8, 2025, https://movefast.tistory.com/341
32. [OS] Operating System - 페이징과 스와핑 - Note - 티스토리, accessed July 8, 2025, https://skyriv312079.tistory.com/255
33. 리눅스 커널 : 메모리 관리 - KLDP Wiki, accessed July 8, 2025, https://wiki.kldp.org/Translations/html/The_Linux_Kernel-KLDP/tlk3.html
34. [운영체제] Memory Management 6 (다단계 페이지 테이블, 역 페이지 테이블, 공유 페이지), accessed July 8, 2025, https://rannnneey.tistory.com/entry/%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C-Memory-Management-6-%EB%8B%A4%EB%8B%A8%EA%B3%84-%ED%8E%98%EC%9D%B4%EC%A7%80-%ED%85%8C%EC%9D%B4%EB%B8%94-%EC%97%AD-%ED%8E%98%EC%9D%B4%EC%A7%80-%ED%85%8C%EC%9D%B4%EB%B8%94-%EA%B3%B5%EC%9C%A0-%ED%8E%98%EC%9D%B4%EC%A7%80
35. 계층적 페이징 계산 과정 – JSYoo5B.Dev();, accessed July 8, 2025, https://devlog.jsyoo5b.net/ko/posts/osc_10th/ch09/hierarchical-paging-calc/
36. [OS] 요구 페이징 - 인성의 개발 공부 노트 - 티스토리, accessed July 8, 2025, https://superohinsung.tistory.com/127
37. [혼공컴운] Chapter 14. 가상 메모리 - velog, accessed July 8, 2025, https://velog.io/@ncookie/Chapter-14.-%EA%B0%80%EC%83%81-%EB%A9%94%EB%AA%A8%EB%A6%AC
38. 리눅스 - 가상 파일 시스템, accessed July 8, 2025, https://dev-ahn.tistory.com/97
39. VFS : Virtual File System - Introduction - foon’s 작업실 - 티스토리, accessed July 8, 2025, https://bearfoon.tistory.com/m/27?category=432041
40. 가상 파일 시스템 VFS - velog, accessed July 8, 2025, https://velog.io/@ooweatah/%EA%B0%80%EC%83%81-%ED%8C%8C%EC%9D%BC-%EC%8B%9C%EC%8A%A4%ED%85%9C-VFS
41. 리눅스 커널 공부 정리 0x04 - 가상 파일 시스템, accessed July 8, 2025, https://5kyc1ad.tistory.com/275
42. Linux VFS(Virtual File System), superblock, inode, file, dentry - 정보시스템감리사, 정보관리기술사 - 티스토리, accessed July 8, 2025, https://swingswing.tistory.com/319
43. VFS 1 - 가상 파일시스템(Virtual File System) - velog, accessed July 8, 2025, https://velog.io/@jinh2352/%EA%B0%80%EC%83%81-%ED%8C%8C%EC%9D%BC%EC%8B%9C%EC%8A%A4%ED%85%9CVirtual-File-System
44. [LinuxKernel]파일시스템, 가상 파일시스템, 슈퍼블록, 아이노드, 덴트리, 파일(FileSystem, VFS, SuperBlock, Inode, Dentry, File) - Hyo Note - 티스토리, accessed July 8, 2025, https://hyoje420.tistory.com/53
45. [VFS] - Development - 티스토리, accessed July 8, 2025, https://4369.tistory.com/entry/VFS
46. [LKM] Character Device Driver - Karatus - 티스토리, accessed July 8, 2025, https://karatus.tistory.com/206
47. [ Section 2 ] 리눅스 시스템 개발 관련 생태계 - velog, accessed July 8, 2025, https://velog.io/@hyejinkwon/Section-2-%EB%A6%AC%EB%88%85%EC%8A%A4-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B0%9C%EB%B0%9C-%EA%B4%80%EB%A0%A8-%EC%83%9D%ED%83%9C%EA%B3%84-3790e4a3
48. [Linux Kernel] 리눅스 커널 개발 가이드: Introduction - Endless Learning, accessed July 8, 2025, https://hyeyoo.com/110
49. Windows NT vs. Unix: 설계 비교 | GeekNews, accessed July 8, 2025, https://news.hada.io/topic?id=16692
50. XNU - 나무위키, accessed July 8, 2025, https://namu.wiki/w/XNU
51. 리눅스가 윈도우보다 훨씬 더 빠른 것처럼 보이는 이유는 뭐임? : r/linux, accessed July 8, 2025, https://www.reddit.com/r/linux/comments/9gwphj/why_does_linux_seem_to_be_an_order_of_magnitude/?tl=ko
52. [논문 리뷰] Rusty Linux: Advances in Rust for Linux Kernel …, accessed July 8, 2025, https://www.themoonlight.io/ko/review/rusty-linux-advances-in-rust-for-linux-kernel-development
53. Greg K-H: “Rust로 새로운 코드 작성은 모두에게 이익” | GeekNews, accessed July 8, 2025, https://news.hada.io/topic?id=19346
54. Rust - TQCS, accessed July 8, 2025, https://www.tqcs.io/rust-kr.html
55. Rust(프로그래밍 언어) - 나무위키, accessed July 8, 2025, https://namu.wiki/w/Rust(%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D%20%EC%96%B8%EC%96%B4)
56. Rust, 소유권으로 memory safety와 thread safety를 만나다 - 설명탕, accessed July 8, 2025, https://redundant4u.com/post/rust
57. 리눅스커널 러스트 논쟁, 다시 불타오르다 – 바이라인네트워크, accessed July 8, 2025, https://byline.network/2025/02/12-381/
58. “러스트는 암적인 요소”… 리눅스 커널 개발자간 논란 심화 - Daum, accessed July 8, 2025, https://v.daum.net/v/20250207101150346?f=p
59. “비생산적 논쟁에 지쳤다”…리눅스커널 러스트 전환 담당자 사임 - 지디넷코리아, accessed July 8, 2025, https://zdnet.co.kr/view/?no=20240909094905
60. 리눅스 러스트 논쟁으로 불거진 ‘오픈소스 번아웃’ - 바이라인네트워크, accessed July 8, 2025, https://byline.network/2025/02/19-436/
61. 리눅스커널 러스트 논쟁, 다시 불타오르다 - GeekNews, accessed July 8, 2025, https://news.hada.io/topic?id=19211
62. 리눅스 커널에 ‘러스트’ 쓰는 날 올까 - 지디넷코리아, accessed July 8, 2025, https://zdnet.co.kr/view/?no=20210330064519
63. “러스트는 암적인 요소”… 리눅스 커널 개발자간 논란 심화 - 지디넷코리아, accessed July 8, 2025, https://zdnet.co.kr/view/?no=20250207101134
64. 리눅스 커널 로컬 권한 상승 취약점 (CVE-2022-0847) - MIR TEAM - 티스토리, accessed July 8, 2025, https://mirteam.tistory.com/44
65. 리눅스 커널 보안 취약점, 발견 2년 후에도 여전히 악용 중 - SK쉴더스 루키즈, accessed July 8, 2025, https://sslc.kr/board/news/1055
66. 리눅스 커널 취약점 CVE-2024-53104, CISA 긴급 패치 권고 - 인스피언 공식 블로그 - 티스토리, accessed July 8, 2025, https://inspien01.tistory.com/entry/%EB%A6%AC%EB%88%85%EC%8A%A4-%EC%BB%A4%EB%84%90-%EC%B7%A8%EC%95%BD%EC%A0%90-CVE-2024-53104-CISA-%EA%B8%B4%EA%B8%89-%ED%8C%A8%EC%B9%98-%EA%B6%8C%EA%B3%A0
67. 리눅스 커널 보안 업데이트 권고 - 보안 취약점 정보 포털, accessed July 8, 2025, https://knvd.krcert.or.kr/detailSecNo.do?IDX=6389